A computer program (or simply “program”) is a sequence of instructions that define the actions or computations that will be carried out by a computer when the instructions are loaded and executed. To run a program, the computer is initialized to a starting state, the program and sometimes data are loaded and some mechanism that executes the loaded instructions is invoked. In most computers, an operating system loads and executes the program. In this context, a program refers to an individual executable image rather than all the programming currently running on the computer. Thus the word “program” describes a single, complete and more-or-less self-contained list of instructions, often stored in a single file, whereas “code” and “software” are words of indefinite number describing some number of instructions which may constitute one or more programs or parts thereof.
System software is any software required to support the production or execution of application programs but which is not specific to any particular application. The operating system, compilers, editors and sorting programs are well-known examples of system software. Application programs typically perform a special function: word-processing or computer-aided-design (CAD), for example. Most programs rely heavily on various kinds of operating system software for their execution.
While the word “program” refers to a static binary image that contains a set of instructions that can be executed, a “process” is the operating system's representation of a container that is used to load and execute code. The code executed by a process exists in its address space; the code may be loaded into the address space from an executable program or library file, or it may be dynamically generated by code already executing in the process.
In general, a process includes memory, (typically a region of virtual memory for suspended processes) which contains the executable program code and private or task-specific data; operating system resources that are allocated to the process, such as file descriptors (Unix terminology) or handles (Windows terminology); security attributes, such as the process owner and the rules describing the access rights other processes/threads may obtain to the process (depending on their security context); and processor state, such as the content of registers, physical memory addresses, etc.
The system typically associates one or more threads with a process to execute code; thus the relationship between threads and processes is many to one. When a process runs, one or more of its threads is actively executing on a processor in the system. In most operating systems, many processes exist simultaneously on a computer, each one taking turns receiving processing time (in a time-slicing system) or running concurrently (in a multiprocessing system). For the most part, the operating system keeps processes isolated from one another. However, the operating system typically provides mechanisms for inter-process communication (for example, messaging functionality or shareable memory) to enable processes to interact.
A process can invoke the operating system to create a new process; the latter is often called a child process and the initiating process is sometimes referred to as its parent. A child process may be a replica of the parent process and may share some of its resources. A child process may inherit most of the attributes of its parent. In UNIX, a child process is created (using fork) as a copy of the parent. The child process can then overlay itself with a different program (using exec) as required. Each process may create many child processes but will have only one parent process, except for the very first process which has no parent. The first process, called init in UNIX, is started by the kernel at booting time and never terminates. In the NT operating system, the kernel creates a special system process during system initialization that provides an execution environment for system threads (threads that execute in the operating system's address space). Later in the system initialization process the system process creates a user-mode process known as the session manager (SMSS) in order to complete the user-mode initialization of the system. NT supports the notion of address space duplication in which certain portions of the parent's address space are cloned for a child process. Handles to system resources may optionally be propagated to a child process if they are marked “inheritable” and the parent process indicates that it desires such inheritance. Alternatively, an entirely new process may be created without the need for the intermediary fork( ) step used in UNIX.
The operating system typically associates some form of security with a process. In a multi-user operating system, this is necessary in order to prevent one user from accessing or modifying the state of another users' process. Without this security a malicious user could take control of another user's process and steal valuable data such as a password stored in the process address space. In NT the default security context for a process is implicitly inherited from the creating process or is explicitly supplied to the operating system by the creating process. This context typically reflects the user the process is executing on behalf of, and governs the access the process can have to various system resources, including other processes. The system also associates a security descriptor with the newly created process object that delineates the access rights other users can obtain to the object. Note that the creator is marked as the owner of the new object, which ensures that the creator can obtain full access to the new process. However, if run by certain users, any process can access the state of another process or inject threads of execution into another process. In most traditional operating systems, the system administrator is capable of accomplishing this. NT expands upon this basic security model by adding the notion of privileges that bypass the standard user/group based protections. For example, a user granted the debug privilege by an administrator will also have unrestricted access to any process running on the system. Unfortunately this security model poses some difficulty for the wave of emerging digital rights management (DRM) technologies. DRM technologies fundamentally require the ability to operate on “protected content” within a process whilst preventing the user (the creator) from recovering a hidden key or secret used to decode the content, or subvert the terms of a license associated with the content. Though capturing any decoded content from a DRM process (and distributing it outside the context of the DRM process) is a concern, it is the content key that is typically the most valued asset. Once recovered, it empowers a malicious user to decrypt or subvert the terms of a license surrounding any protected content. Fundamentally the DRM problem is difficult to completely solve since the secret typically must reside somewhere on the client machine, and furthermore, must be processed by the DRM process during the course of accessing protected content. A certain degree of protection for the secrets and content in a DRM process can be provided if the operating system implemented a mechanism to execute a process and shield it from certain known invasive operations performed by another process, regardless of the latter's security context or privilege level.